因為前端在工作上有絕大部分都需要跟後端緊密合作
所以阿宅 PO 認為可以對後端工作內容和部分特性有一定程度了解
在協作上是很有幫助的！

以下介紹幾個跟後端有些許相關的日常情境

API 格式 與 HTTP Method

這個部分通常是要看公司後端的 API 寫法採用哪一個風格
目前阿宅 PO 大部分遇到的都是 公司後端自己定義的風格，僅少部分採用 RESTful API 的風格。

欸！！！ 是的，RESTful API 是 API 的一種寫作風格唷！，不是 Call API 的方法唷～ (新人坑單押＊1)

簡單帶一下 RESTful API 有提供哪些 API/HTTP 請求方法：

• GET 讀取資源
• PUT 替換資源
• PATCH 更換資源部分內容
• DELETE 刪除資源
• OPTIONS 回傳該資源所支援的所有 HTTP 請求方法
• CONNECT 將連線請求轉換至 TCP/IP 隧道
• POST 新增資源

如果你任職的公司是由後端自行定義 API/HTTP 請求方法的話，則是看 後端同仁 定義的設計風格。
像是 Call API 是要使用 GET 或 POST，就是要看後端支援哪一種寫法唷～～

超簡介資料庫架構 與 溝通小眉角

因為開發專案/產品時，會需要跟後端溝通 API 回傳的資料格式

這裡幫大家插播一小段，資料庫架構的部分：

資料庫可以將它想成是一個大型資料夾，裡面放著一張張像 Excel 的資料表（Table）

如果我們前端所收集、取得的資料需要被記錄起來時（EX: 會員資料），則需要透過 API 傳遞到伺服器，後端在處理之後，分門別類的一欄欄存到資料表內。

流程大致會像這樣：
前端從介面取得資料 → 透過後端提供的 API 將資料傳送到伺服器 → 後端處理過後，存到資料表

題外話，前端是無法也不建議直接操作資料庫喔～

了解完簡單的資料庫架構 和 資料傳遞流程後，我們回到溝通 API 回傳的資料格式這一 Part，來說說 溝通 的小眉角！

透過上方說明，我們可以知道，平常 Call API 回來的資料們，都是來自於資料庫那一張張資料表的欄位組合而成，這些資料表的欄位設計與資料表的拆分，是由後端處理與設計的

在開發前期、中期有較大的機率會發生客戶新增需求的狀況，當遇到這樣的情況時，會由 PM 了解完需求並確認功能細項之後跟 RD 們開會討論
如果畫面需要秀出一些當初溝通 API 回傳的資料格式中沒有的項目時，就會需要後端去調整資料表的欄位～

優秀的前端同仁們，這時在跟後端溝通時，
*千萬嗯湯* 跟後端同仁說：「這個只要加個欄位就可以解決了吧！？ 應該不難才對」

恭喜獲得內心無限幹剿的後端同仁一隻或一群...
[這邊幫阿宅 PO 身邊熟識的後端朋友們發聲～～]

鐵人賽來到了第 29 天～～
於是調動了一下原先的文章配置
希望大家會喜歡～～